What is seniority in software engineering ? An attempt to qualify it

This article is an essay trying to go deeper in the notion of "seniority". What is seniority ? experience ? But what experience ?

Disclaimer: This article is an essay written from my personal experience. It is not supposed to be a scientific article that bring some absolute thruth. Every constructive comments are welcome.

Introduction

We see a lot of job offers, coworkers, teammates talking about "seniority". Even if the definition of seniority differs from one company to another, the consensus is that he is a more experienced person that handles more responsibility and has a broader job requirement. Also, the level of "seniority" can be higher following the company. Indeed, a senior from a GAFAM has a probability to be more skilled that a senior in a local tech company.

However, it seems that there is no common full definition of it. Is it a mirror of years of experience ? the result of meeting various contexts or making a lots of mistakes ? A bit of evrything said before ?

Let's break up some misconception beforehand, I do think that years of experience have at most a minor impact on seniority. If you debug the same application without asking questions for years, your technical and business knowledge won't increase much. Hence, seniority comes with curiosity and going outside your job day-to-day routine, your comfort zone to take risks and be in your boldness zone.

So, what is the aspects of a senior ?

The common characteristics of a "senior"

Usually, the senior one is the most reliable person on the develoment team. He is the most important person, without him the software has good chances to become unmaintainable quite fast because of lack of lisibility and extensibility. Indeed, an unmaintanble software lead to an explosion of costs, a decrease of deliveries and difficulties to attract new poeple. Which can lead a company to its demise.

The senior can handle complex code, help the team to enhance their skills and help the project board to take the best decisions.

However, in my career, i saw that "seniority" can be splitted into 2 types: the "familiar" and the "technical expert".

Familairity ? Expertise ?

What is the "familiar" and the "technical expert" ?

On the first hand, the familiar is someone that is an expert / specialist of a domain apart from the project / business. It is usually the person that is in the company for several years or decades and know everyone, the domain etc... He knows all or most of the history of the project/product or company. He is a precious person because:

• He can warn of the potential obstacles if someone wants to introduce some new stuff
• He knows at least most of the source code so he can help teammates to troubleshoot bugs and creates new feature
• He knows most of poeple and can deal with potential processes issues
• ease onboardings

On the contrary, his limits are:

• he has not a very deep technical knowledge compared to the other one.
• He can be a "guard temple" blocking most of the innovation attempts of the team

To become one is quite simple, you just have to stay in the company. It rewards stability.

On the other hand, the technical expert is, as the name suggest, a specialist of a technical subject like architectural patterns/frameworks and so on... He knows less about the domain or the project itself but knows the limits of its area of expertise. He is also a very important person because:

• He can deal with most of the technical issues very fast
• provide some "external eye" on a subject and bring some innovation
• help teammates on their technical expertise
• speed up development and prevents unmaintability issues
• warn of the potential issues for a specific issue (framework, architecture etc...)

However he can be a burden because:

• He has no deep knowledge of the company context
• He can promote some very risky changes

Contrary to the familiar one, I advise to switch context and subjects regularly to catch enough experience to go deeper in your choosen fields. It rewards instability.

We can go deeper if we include de years of experience in there:

I think that a familiar that has too few years of experience is very unlikely to have. Namely, it means someone that knows the business and the company very well but with few years of presence. Unless you have the sun of the CEO and he is very invested from the beginning, i don't think someone can.

As a manager, the 3 other personas have their place in a team, especially the young expert. He is someone very talented that a manager has to help him grow and cherish. The remaining two, the familiar and the expert with lots of years of experience are the most common cases.

In my opinion, there is no good or bad one, they are very complementary and i think that a team need both to operate smoothly.

How they can interact each other ? and how we can organize a team ?

As they are compatible, the interaction should come up very naturally. Each member will fill the weakness of the other.

As they are veterans, the manager should aproach them equally and with the same management style: a very participative one. They have to be included in all aspects of decisions. Indeed, one can warn if some new idea have already been tested before and explain why it has failed and the other can propose new technical ideas. They are the leaders of the development team.

Off course, these types can be embodied by the same person: lucky for you! Cherish him and do everything to keep him motivated and afloat. However, as a managerial mindset, he is a valuable resource and also the biggest risks. He can be some kind of "hero" preventing the team to succeed as a all. Moreover, if he is not present for random reasons (sickness, quitting, parental leave etc...) the team will suffer and productivity also. Thus, the task of the manager is to create a system where the knowledge and expertise is shared between teammates. Here is some avenues:

• favor pair programming and mob programming
• hunt information retention
• share regularly technical surveillance
• do code reviews

Also, some Domain Driven Design principles like event storming can help your team discover the business and become more familiar.

Conclusion

The concept of seniority is quite vague and very context-dependant to provide an exhaustive definition. Nevertheless, I think that this split can help managers and teams to better select their seniors and make a more balanced team.

TL;DR

• there is two types of seniority: familiarity and technical expertise
• Familiarity is the fact that someone knows very well the project/source code/business context
• Technical expertise is someone that has a deep knowledge of its area of expertise regardless the project
• Both are very valuable and complementary person for a project to succeed
• Both have to be treated equaly and no hierarchy should be put in them. Both have to lead the team and the younger persons